Five Whys

Five Whysへの異論反論

Atlassianのポストモーテムの記事中で議論されているFive Whysの誤解と真実。

Five whysは責任追及の文化を生む

問題の特定は、その問題に関与した人を責めることとは違う。Five whysの基本ルールの1つは、根本的な原因を人に求めないことだ。

何がヒューマンエラーを引き起こしたのか?

失敗の原因は何か?

どのようなプロセス、変更可能な行動、文化的な要因があるのか?

に着目する。

このとき後知恵を捨てるのも重要だ。(The Field Guide to Understanding Human Errorより)

失敗という結果と、悪いプロセスはセットではない。

人々がすべきだったこと、やるべきでなかったこと、という仮定の話に深入りしない。

行動の是非でなく、その行動の理由を当事者になったつもりで理解する。

個人の欠点(判断力)に原因を求めない (時間不足、注意不足など)

時間的、空間的に事故にもっとも近いところにいた人、あるいは事故を防げる可能性のあった人だけにフォーカスするのをやめる。

Fiveは多すぎる/少なすぎる

Five Whysという名前だからといって、文字通り5回なぜを繰り返せということではない。

根本原因が1つだけってのは滅多に無い

別に1つだけにしろ、という話はどこにもない。因果関係の連鎖が、複数の要因からなるツリー状になっていても大丈夫。

全体的にみて十分じゃない

Five Whysは技術的な原因と結果を特定するだけではない。あなたのチームがそれらの要因を無視していない限り、プロセス、文化、大局的な事業状況を原因に求めれば良い。

知らないことを知ることはできない

一部の人だけで、Five Whysをやっても十分な根本原因に行き当たることができないかもしれない。Five Whysはチームワークであり、インシデントに関わった全員が、その事後処理に関わるべきだ。

ヒューマンエラーは出発点で、そこから掘り下げる。

人間ではなく、システムを指し示す答えを探す。

実際に発生しなかったものを因果関係としない

例えば「ビルドパイプラインが異常終了した」という問題についてFive Whysするとする。

その結果、1段目のWhyは「ディスクが一杯で書き込みできなかった」という事実に到達する。

問題はここからで、次のWhyとして以下のようなものを考えがちだが…

管理者が過去のビルド結果をパージしていなかった

ディスクの状態をモニタリングしていなかった

これは「しなかった」ことであり、実際に起きたことではない。実際には発生しなかったことは無限に考えられるので、いくらでもWhyを紡いでいけて「地球が居住可能じゃなければ、だれもビルド失敗を気にする人はいないだろう」などに行き着くことも可能だ。

また、「しなかった」ことは、人の過失と捉えることができてしまうので、責任追及に話が行きがちで「非難の嵐」をうむことになる。

この「事実じゃないこと」はFive Whysの掘り下げに使うのではなく、辿り着いた根本原因からアクションアイテムを構築するときには有用なものとして使える。なのでFive Whysの途中で誰かが「しなかったこと」を言ったら、棄却するけれどもそれをどこかに記録しておいて、その後アクションアイテムを考えるときに使おう。